A microservice design architecture is based on design philosophy that posits that it is easier to design many individual and independent microservices that each perform a single task, or a single subset of tasks, than it is to design a large monolithic service that is responsible for performing multiple disparate tasks. Consequently, in microservice design architecture, multiple discrete functions that are likely to be utilized together can be implemented by multiple different and independent teams of programmers. Such division can introduce difficulties when attempting to monitor the design and performance of an overall service comprised of many such microservices.
One mechanism for attempting to monitor an overall service comprised of such microservices is based on a siloed approach, whereby each microservice is individually understood within its own service boundaries, including an understanding of the data or functionality that such a microservice will consume and the data or functionality that such a microservice will output. Overall understanding of the service, therefore, requires translating between the constructs defined within each individual microservice. Moreover, because each individual micro service is independently understood, it is only the microservices directly providing data or functionality to such a microservice, or the micro services directly consuming data functionality from such a micro service that are known. A multi-hop understanding of the overall service cannot be known. A crawler mechanism can be utilized to collect information from each individual microservice and piece together an overall understanding based on information from each individual microservice regarding the execution context of an individual microservice. Such crawler mechanism requires that the crawler be informed of any changes to the individual microservices because otherwise those changes will nullify any overall understanding pieced together by the crawler.
Yet another alternative mechanism requires each individual microservice to identify data exchanged with other microservices with unique identifiers, or tokens. But such a mechanism requires that each microservice rigorously pass such tokens to each subsequent microservice, since the failure of any one microservice to properly pass a token can affect all downstream microservices. The passing of tokens can also be unwieldy when multiple different microservices pass the same token from a previously forked execution context into a single receiving microservice, thereby joining back the previously forked execution context. Existing approaches, therefore, either create a linear chain of tokens, such as a linked list, or a tree of tokens, such as call stacks underneath a chain of tokens.